This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
Mobile multicast and broadcast systems have recently been standardized by different organizations, such as the 3rd Generation Partnership Project (3GPP) Multimedia Broadcast/Multicast Service (MBMS), the Digital Video Broadcasting (DVB) Technical Module Convergence of Broadcast and Mobile Services (TM-CBMS), and the Open Mobile Alliance (OMA) Mobile Broadcast Services (BCAST) organizations. Other multicast and broadcast systems further include Integrated Services Digital Broadcasting-Terrestrial (ISDB-T), Digital Multimedia Broadcast-Terrestrial/Handheld (DMB-T/H), Digital Multimedia Broadcasting (T-DMB), Forward Link Only (FLO) and proprietary systems, such as for example, MediaFLO. Two primary services provided by such multicast/broadcast solutions are streaming and file delivery services. Although streaming services are considered to be the primary driver of the technology (e.g., the Mobile TV application), file delivery is expected to generate a significant amount of the traffic, as well as a significant amount of the revenues. For example, in the delivery of music and video clips, the file delivery may comprise the primary application component. Alternatively, file delivery may be a secondary component of the application, such as in the case of rich media applications and zapping streams.
In the case of file delivery, File Delivery over Unidirectional Transport (FLUTE) can be used as the file delivery protocol. FLUTE is defined by the Internet Engineering Task Force (IETF) and is based on the Asynchonous Layered Coding (ALC) Protocol Instantiation. ALC comprises a set of building blocks such as the Layered Coding Transport (LCT) block and the Forward Error Correction (FEC) building block. FLUTE extends ALC by, among others, defining mechanisms to describe the contents of the FLUTE session. This is achieved by introducing a well-known object with a Transport Object Identifier (TOI) equal to 0, carrying a File Delivery Table (FDT) instance. The FDT instance lists a set of files and their corresponding transport options. The FDT is an XML file following a schema defined in the FLUTE specification.
Another component of multicast and broadcast services is referred to as a notification service. Notification services complement mobile TV services by offering a way to enable interactivity and delivery of service related information, while also enabling new and/or critical services, such as emergency notifications. A Tsunami notification service is an example of an emergency notification.
DVB TM-CBMS is currently defining a notification framework under the scope of a next Internet Protocol Datacast system (IPDC), IPDC 2.0, that seeks to enable the realization of several use cases, which have already been defined. These use cases are described in “IP Datacast over DVB-H: Notification (Living Document)”, TM-CBMS 1520r8, incorporated herein by reference in its entirety. It may be noted that notification use cases can be classified according to the following criteria: whether a notification has strong or loose time constraints, e.g., a notification that should be received within a given time and/or may be processed with various timing requirements; whether a notification is directed to a terminal or to a user, e.g., a notification targeted to the terminal or an application residing thereon, or a notification targeted to the user, where the terminal's involvement in processing the notification goes beyond what is required to present the notification to the user; where a notification is service-related or service-agnostic, a notification that is reliant upon or independent of a service, respectively; and whether a notification requires interactivity or not, e.g., a notification, the main purpose of which is to lead a terminal to subsequent interaction with a network or application.
Notification messages may be large in size if, for example, they contain audio/video and/or other content. Hence, file delivery protocols can be more suitable for the delivery of notification messages when they are bulky. Furthermore, a notification message may be related to a service and have strong synchronization requirements, in addition to possibly requiring some of amount of interactivity. An example of such a notification service is a voting service, which can be tightly synchronized to a service, such as a TV broadcast. Viewers are required to vote within a specific time period which may be as short as a couple of seconds. Thus, audio/video streams must generally be synchronized accurately to the notification service. Any inaccurate synchronization may confuse and mislead the viewer, especially if interactive actions are triggered based on the notification message. Hence, Real Transport Protocol (RTP) may be better suited for delivering notification messages having more stringent synchronization requirements. Currently, there are no defined methods for transporting notification messages which are both bulky and which necessitate the use of RTP in light of their content.
OMA BCAST defines a notification functionality that enables the description of a notification service in an Electronic Service Guide (ESG) and the delivery of the notification data over FLUTE, Short Messaging Service (SMS), or OMA-PUSH. An interactivity document can be used to describe the type of required interaction and can be delivered as a part of the notification message. However, the synchronization mechanism is not sufficiently accurate as it relies on Network Time Protocol (NTP) timestamps. In other words, an NTP timestamp may be used to synchronize a notification message to media streams of a related, actual service. A mapping of RTP timestamps to “wallclock” time is performed at a terminal to synchronize the audio/video streams of the actual service. However, the indicated NTP timestamp represents the time at the audio/video stream generator and does not reflect the time at the terminal. Furthermore, the playout of the audio/video stream is usually delayed due to the time needed for de-jitter buffering. Thus, relying on an NTP timestamp, carried in a notification message, may result in a too-early display of the notification message. It is also possible that the clocks of the media stream generator and the notification message generator are different. Hence, NTP timestamps do not guarantee accurate time synchronization.
It should be noted that a notification entity is different from a stream generation entity. In addition, any buffering time that audio/video streams may need in order to trigger the interaction action quickly before corresponding content is shown on the screen is not taken into account.
Furthermore, using RTP extension headers to add synchronization information to audio/video streams has been proposed, while also splitting the notification message into three separate parts. The proposed three separate parts, include: Synchronization marks inserted into RTP extension headers of the audio/video streams of an actual service, where the synchronization marks can carry an interactive object identifier; an Interactive Descriptor that is used to associate an interactive object with the synchronization marks, while also containing other information, such as timing information; and an Interactive Object that can carry the content or description of the notification message. However, this requires modification of the audio/video streams in order to insert and extract any required headers. In addition, the RTP streams need to be intercepted at the receiver in order to extract the extension headers. It is also not clear what long-term effects can result with regard to RTCP statistics because the RTP streams are altered without modifying the synchronization source (SSRC). Conventionally, extension headers are intended to be used by the media stream receiver and not meant to include information that relates to a completely different instance.